home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 9153 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.3 KB
  1. Path: camelot.dsccc.com!not-for-mail
  2. From: kcline@sun152.spd.dsccc.com (Kevin Cline)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: C++ & macros
  5. Date: 28 Feb 1996 18:27:16 -0600
  6. Organization: DSC Communications Corporation Switch Products Division
  7. Message-ID: <4h2rt4$4cg@sun152.spd.dsccc.com>
  8. References: <DLBxoH.GLw@ariel.cs.yorku.ca> <4gg06d$401m@news-s01.ny.us.ibm.net> <4gioa2$nsb@sun152.spd.dsccc.com> <4h0h4o$7a3@xanadu.io.com>
  9. NNTP-Posting-Host: sun152.spd.dsccc.com
  10.  
  11. In article <4h0h4o$7a3@xanadu.io.com>, Jamshid Afshar <jamshid@io.com> wrote:
  12. >In article <4gioa2$nsb@sun152.spd.dsccc.com>,
  13. >Kevin Cline <kcline@sun152.spd.dsccc.com> wrote:
  14. >>    #define FRUIT_LIST \
  15. >>        FRUIT(apple), \
  16. >>        FRUIT(orange), \
  17. >>        FRUIT(pear)
  18. >>
  19. >>    #define FRUIT(t) t
  20. >>    typedef enum { ITEM_LIST } Fruit;
  21. >>    #undef FRUIT
  22. >>
  23. >>    // #t produces a quoted string 
  24. >>    #define FRUIT(t) #t
  25. >>    static const char* const FruitNameTable[] = { ITEM_LIST };
  26. >>    #undef ITEM
  27. >>
  28. >>When the list gets long, techniques like this can be useful for
  29. >>reducing redundancies in source code.  I find that as soon
  30. >>as I have to specify the same thing twice, and the compiler is unable
  31. >>to make sure they match, they won't. 
  32. >
  33.  
  34. >Is the above convenience worth the extra lines of code and comments?
  35. >Is it worth the extra time future maintainers are going to have to
  36. >take figuring out this scheme and verifying in their mind that it does
  37. >what's expected?  
  38.  
  39. To me, it is.  I will go to almost any length to avoid having to
  40. hand-check two copies of the same information for conformance.
  41.  
  42. Although these techniques are unfamiliar to some programmers,
  43. they are not that hard to understand.  The # and ## preprocessor operators   
  44. were created because they met a real need; maintaining meta-data about
  45. C++ compile-time objects is one of them.  
  46.  
  47. I do not worry about writing code that is easy for novice C++
  48. programmers to understand; I write code so it can be maintained with
  49. minimal effort by experienced programmers, and I write code so that
  50. correct compilation means a high probability of correct operation.  To
  51. me, the ten minutes that a new programmer spends understanding the
  52. macro are vastly cheaper than the two or more hours they will spend
  53. debugging the first time the two lists become unsynchronized and a
  54. table lookup fails that should have succeeded.  I write code for
  55. telephone switching equipment.  A bug detected in the field is very
  56. expensive in time and lost goodwill.  If I give some novice programmer
  57. a headache, that's good.  Now they have learned a new way to produce
  58. more maintainable code.
  59.  
  60. Wouldn't it take less time to just copy&paste the
  61. >enumerator list and use your editor's keystroke record and playback to
  62. >safely change the items to string literals?  
  63.  
  64. Yes, but it's error prone.  I'm an expert Emacs user, and can define
  65. keyboard macros in my sleep, but it is much better to use the
  66. compiler to eliminate the possibility of error.    
  67.  
  68. Of course, different
  69. >programmers will have different opinions on this, but I wouldn't want
  70. >to use or maintain macro tricks like the above 
  71.  
  72. >(though I've seen much
  73. >worse -- the "#define GLOBAL extern" trick is especially silly,
  74. >especially when people get fancy and try to add a INIT(value) macro).
  75. >
  76.  
  77. Yes, and it's also totally pointless.  In C++, static member functions 
  78. should almost always be used instead of externs.  
  79.  
  80.  
  81. -- 
  82. Kevin Cline
  83.